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0 Object management and delivery system having multiple object-resolution capability. 



@ A method and apparatus which allows an object 
management and delivery system to perform cap- 
^ture, prefetch, display, print and/or modify operations 
^with only a modicum of interaction between the 
^operations of a host computer system and the object 
CO management and delivery system. Host 
<D computer/object-management system interaction is 
qq typically limited to: operation requests transferred 
^from the host computer to the object management 
CO system; record registration data transferred from the 
q object management system to notify the host com- 
n puter that an object record has been stored; and/or 
error data transferred from the object management 
system to notify the host computer when the object 
management system encounters an error in trying to 

Xerox Copy Centre 




Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



perform an operation requested by the host com- 
puter. 
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OBJECT MANAGEMENT AND DELIVERY SYSTEM HAVING MULTIPLE OBJECT-RESOLUTION CAPABILITY 



The invention disclosed broadly relates to data 
processing-systems a nd; more-p a rtiC M larly r relates- 



along a length of the microfilm can be selected in 
-response-to-the push-of a-button. Thereafter,, any_ 



to an- object management and delivery system 
(OMDS) and having multiple object-resolution capa- 
bility. The disclosed object management and deliv- 
ery system is particularly suited for use as an 
image retrieval/storage system. 

Many attempts have been made in the prior art 
to provide adequate storage for digitized images in 
data processing systems. Early prior art techniques 
were based upon the conversion of photographic 
microfiche records into digitized images which 
were then stored on either magnetic tape or mag- 
netic-disks for-later retrieval-and-display— The-prob— 
lem with the early prior art was that since the 
digitized image records were quite large, substan- 
tial quantities of storage space were required, thus 
limiting the appeal of such systems for practical 
applications. 

As the prior art evolved, digital image compres- 
sion algorithms were developed to convert digitized 
bit patterns for images into a more compressed 
record which could be more conveniently stored on 
magnetic tape or magnetic disk devices. However, 
the size of these compressed records was still 
large enough to present a problem of adequate 
storage. In addition, because of the size of the 
compressed records, access time to retrieve a de- 
sired image from the magnetic tape or magnetic 
disk storage devices was unacceptably long. 

There are many known examples of document 
and/or image storage/retrieval systems: 

Gahske et al (U.S. Patent 4;1 39,901) is directed 
to a document storage and retrieval system includ- 
ing a plurality of remotely disposed control termi- 
nals and microfiche carousel document storage 
files with means for converting microfiche images 
thereon into video signals representative of the 
document and for transferring these video signals 
to a buffer storage unit associated with a request- 
ing control terminal. 

Gilbert (U.S. Patent 4,164,024) is directed to an 
information retrieval system which provides a re- 
trievable updatable display of a permanent micro- 
film record. An updated display is accomplished by 
forming a display of a projected permanent micro- 
film record onto a gas panel display, and supplant- 
ing updated portions by blanking or by overwriting 
predetermined portions of the display with updated 
information. 

Johnson et al (U.S. Patent 4,174,890) is di- 
rected to a microfilm utilization device wherein a 
special bar code is printed along the edge of the 
microfilm, and wherein an automatic call-up feature 
can be used so that any given photographic area 
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image on the microfilm may be selected for projec- 
tion by a manual movement in second and third 
dimensions of a simple lens-positioning mecha- 
nism. 

Sukonick et af (U.S. Patent 4,197,590) is di- 
rected to a computer graphic display system in- 
cluding a random access raster memory for storing 
data to be displayed. Zoom, pan, split-screen and 
XOR features can be utilized for the manipulation 
of a displayed image. 

Ovshinsky et al (U.S. Patent 4,205,387) is di- 
-rected— to-a-data storage-and-retrieval-system- 
wherein miniaturized heating heads are used to 
produce a selection of sizes of alpha-numeric, pic- 
torial or digital coded images on a heat-responsive 
recording medium. 

Kimoto (U.S. Patent 4,485,454) is directed to 
an electronic document information filing system in 
which retrieval data are stored to include a number 
of codes. Operator keying requirements for the 
retrieval of documents are minimized because an 
operator can input desired codes, and the system 
will then search for and display a number of selec- 
table retrieval data containing the desired codes. 

Smutek et al (U.S. Patent 4,553,206) is directed 
to an image storage and retrieval technique in 
which digitized information is broken up into blocks 
of a fixed byte size, and each block stored in 
memory has a header associated therewith, the 
header identifying the digitized information, detail- 
ing how the image was digitized and compressed, 
and having an address of any other block contain- 
ing related information for the same image, thereby 
to create between blocks a chaining by which all 
blocks related to an image can be quickly located 
once a first block is located using an index. 

Froessl (U.S. Patent 4,553,261) is directed to a 
document and data handling system wherein each 
document is marked with a unique identifier code 
and then scanned, digitally encoded, and then 
stored. The system also includes conversion of 
digitally encoded portions into machine code. 

Kato (U.S. Patent 4,574,395) is directed to a 
picture image filing apparatus which avoids manual 
input of retrieval data. Retrieval data to be used in 
retrieving picture image data from an image mem- 
ory are carried at a predetermined location on an 
original document itself, and are converted to com- 
puter data by the application of a pattern recogni- 
tion process to digitized data signals from a scan- 
ning operation applied to the predetermined loca- 
tion. 

Yoneyama et al (U.S. Patent 4,601,003) is di- 
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rected to a document storage and rearrangement 
system which gives a user a visual perception of 
an actual office storage operation. A first picture 
image pattern provides an operator with a model 
image representation of a typical office work loca- 
tion,^, a desk, liHng cabi net, waste-basket, eta ( _ 



It is therefore an object of the invention to 
provide an improved object management and deliv- 
ery system which is particularly suited for image 
storage/retrieval. 

5 It is another object of the invention to provide 

an_im proy ed object manage mj^^ 

tern which has a fast access time to access stored 
objects. 

A further object of the invention is to provide 
w an improved object management and delivery sys- 
tem which imposes a lower traffic volume on com- 
munications systems connected therewith. 

Still a further object of the invention is to pro- 
vide an improved image storage/retrieval system 
15 which has a fast access time for stored images, 
has a reduced impact on the communications traf- 
fic, and yet provides for the availability of high 
re solution ima g es. 



and a second picture image pattern presents a 
visual representation of the document contents of 
one of the many file folders stored in the system, 

Ciampa et al (U.S. Patent 4,635,136) is di- 
rected to a method and apparatus for storing a 
massive inventory of labeled images (e.g., cor- 
responding to real estate parcels), wherein each 
labeled image is stored on and produced from a 
different frame of a video disk. 

Van Tyne (U.S. Patent 4.672.186) is directed to 
a digital document scanning system including a 
scanner which permits the presence or abse nce of 



a document to be detected and allows dynamic 
adjustment of threshold levels, thereby accommo- 
dating documents which utilize shaded back- 
grounds. 

Hirose et al (U.S. Patent 4,727,589) is directed 
to a picture data storage/retrieval system where a 
plurality of picture data storage/retrieval ap- 
paratuses are connected to each other through a 
communication line, and wherein a given apparatus 
can request a registration, retrieval or deletion of 
picture data in a another apparatus. 

Berarducci (WO 87-04826) is directed to a 
multi-processor apparatus having two data busses 
and being especially suitable for use in processing 
digital image signals, wherein data can be trans- 
ferred from a processor to a memory unit while at 
the same time data are being transferred from a 
memory unit to a processor. 

Morton , (WO 87 05767) and Morton (WO 
87'05768) are directed to a digital image commu- 
nications network having dual communication chan- 
nels, i.e., a control channel which handles commu- 
nication data, and an image channel used for the 
exclusive transmission of images. 

The prior art has failed to provide an object 
management and delivery system (OMDS) which 
will provide fast access time for either magnetic or 
optical disk storage, will have a minimized commu- 
nications traffic on the communications networks 
used by the object management and retrieval sys- 
tem, and yet will maintain the availability of high 
resolution images for occasional high resolution 
requirements when the object management and 
retrieval system is utilized for image 
storage/retrieval. Further, the prior art has failed to 
provide an object management and retrieval sys- 
tem which can perform desired object-related oper- 
ations with only a modicum of interactions between 
the operations of a host computing system and 
said object management and retrieval system. 



A further object of the invention is to provide 
20 an improved data processing system wherein an 
object management and delivery system can per- 
form desired object-related operations with only a 
modicum of interaction between the operations of a 
host computing system and said object manage- 
as ment and delivery system. 

Another object of the invention is to provide an 
improved data processing system wherein an ob- 
ject management and delivery system can perform 
object capture, prefetch, display, print and/or modi- 
30 fy operations with only a modicum of interaction 
between the operations of a host computer system 
and said object management and delivery system. 

These and other objects, features and advan- 
tages of the invention are accomplished by an 
35 object management and delivery system particu- 
larly suited as an image storage/retrieval system 
having the multiple image resolution capability- dis- 
closed herein. 

A data processing system is disclosed for the 
40 storage/retrieval and display of objects and docu- 
ment images, and includes a workstation having a 
document input scanner coupled thereto for digitiz- 
ing document images at a first resolution, an image 
display unit for displaying digitized document im- 
45 ages at a second resolution which is less than the 
first resolution and a printer for printing digitized 
document images at a third resolution greater than 
the second resolution, the workstation being coup- 
led to an object storage and delivery manager 
so (OSDM) and storage. 

The system includes in the workstation a high- 
er resolution bit plane memory having an input 
coupled to the document scanner for receiving a 
digitized document image at the first resolution. 
55 The system further includes a higher resolution 
image compression unit coupled to the higher res- 
olution bit plane memory and having an output 
coupled to the image host computer, for compress- 
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ing an object or the first resolution digitized docu- 
ment image and outputting a first compressed im- 
age record to the object storage and delivery man- 
ager for storage. 

Jhe system farther incjudes_a first otyect Jtor- 

age unit coupled to the object storage and delivery 
manager for storing compressed records of objects 
and images digitized at the first resolution, the 
object storage and delivery manager storing the 
first compressed image record in the first object 
storage unit. 

The system further includes a resolution modi- 
fication unit having an input coupled to the higher 
resolution bit plane memory, for reducing the reso- 
lution of the first resolution digitized object or docu- 
ment image to the second resolution and for out- 
puttin g a second r esolution di g itized ob j ect or doc- 



The system further includes a printer having an 
input coupled to the image scaling unit, for receiv- 
ing the third resolution digitized object or document 
image for printing, 

Also included is a lower resolution object de- 



compression unit, having an input coupled to tne 
object storage and deliver manager, for receiving 
and decompressing the second compressed object 
or image record from the second object storage 

io unit to restore the second resolution digitized ob- 
ject or document image. 

Furthermore, the lower resolution bit plane 
memory has an input coupled to the lower resolu- 
tion object decompression unit for receiving the 

;s second resolution digitized object or document im- 
age for display on the image display unit. 
T he resultin g s ystem reduces communications 
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ument image. 

The system further includes in the workstation 
a lower resolution bit plane memory having an 20 
input coupled to the resolution modification unit for 
receiving the second resolution digitized object or 
document image. 

Furthermore, the image display unit has an 
input coupled to the lower resolution bit plane 
memory for receiving the second resolution digitiz- 
ed image or document image for display. 

The system additionally includes a lower reso- 
lution image compression unit coupled to the lower 
resolution bit plane memory and having an" output 
coupled to the image host computer, for compress- 
ing the second resolution digitized object or docu- 
ment image and outputting a second compressed 
image object or record to the object storage and 
delivery manager for storage, the second com- 
pressed image object or record being smaller in 
size than the first compressed object or image 
record. 

The system further includes a second object 
storage unit coupled to the object storage and 40 
delivery manager for storing compressed records 
of objects or images digitized at the second resolu- 
tion, the object storage and delivery manager stor- 
ing the second compressed object or image record 
in the second object storage unit. 

The system further includes a higher resolution 
object decompression unit, having an input coupled 
to the object storage and delivery manager, for 
receiving and decompressing the first compressed 
object or image record from the first object storage 
unit to restore the first resolution digitized object or 
document image. 

The system further includes an object or image 
scaling unit, having an input coupled to the higher 
resolution object decompression unit, for convert- 55 
ing the first resolution digitized object or document 
image into a third resolution digitized object or 
document image having the third resolution. 
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traffic on the network because of the smaller com- 
pressed data records which are transmitted for the 
low resolution operations. Access time for storing 
and reading the lower resolution compressed data 
records is aiso reduced; however, this lower traffic 
and faster access time are obtained without sac- 
rificing the availability of high resolution com- 
pressed data records which are occasionally need- 
ed for printing and other high resolution operations. 

Also, the resulting method allows an object 
delivery and management system to perform ob- 
ject capture, prefetch, display, print and/or modify 
operations with only a modicum of interactions 
between the operations of a host computer system 
and the object management and delivery system. 

The novel features believed characteristic of 
the invention are set forth in the appended claims. 
The invention itself, however as well as a preferred 
mode, further objects and advantages thereof, will 
best be understood by reference to the following 
detailed description of an illustrative embodiment 
and to the accompanying drawings, wherein: 

FIG. 1 is a block diagram illustrating local 
and remote data processing systems each com- 
prising an object management and delivery system 
associated with a host computing system. 

FIG. 2 is an architectural block diagram of 
the workstation of the dual resolution digital object 
system. 

FIG. 3 is a hardware block diagram of the 
workstation. 

FIG. 4 is a depiction of a higher resolution 
record including both a higher resolution bit plane 
and corresponding compressed higher resolution 
data. 

FIG. 5 depicts a lower resolution record in- 
cluding both a lower resolution bit plane and cor- 
responding compressed lower resolution data. 

FIG. 6 is an data flow diagram of a store 
operation for the invention. 

FIG. 7 is an data flow diagram of a display 
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operation for the Invention. 

FiG-8-is~an-data-flow-diagram-of-a-modify- 



operation for the invention. 

FIG. 9 is an data flow diagram of a print 
operation for the invention. 
FIG._ VCHs an_e^emjDlaryj^^ 



Further, throughout the discussions to follow, 

severahcomputer-commands-are-revealed-as-hav-- 

ing been constructed and transmitted. These com- 
mands will be only generally discussed since, as 
5 will be appreciated by one skilled in the computer 
art. Jhe_exact construction of_a computer .command,. 



vention. 

FIG. 11 is an exemplary management class 
definition table. 

FIGS. 12A and 12B are processing and 
flowchart diagrams, respectively, for a capture op- 
eration. 

FIGS. 13A and 13B are processing and 
flowchart diagrams, respectively, for a prefetch op- 
eration. 

FIGS. 14A and 14B are processing and 
flowchart diagrams, respectively, for a display op- 
eration. „ 

FIGS. 15A and 15B are processing and 
flowchart diagrams, respectively, for a print opera- 
tion, as initiated from a host computing data termi- 
nal. 

FIGS. 16A and 16B are processing and 
flowchart diagrams, respectively, for a print opera- 
tion, as initiated from an object terminal. 

FIGS. 17A and 17B are processing and 
flowchart diagrams, respectively, for a print opera- 
tion, as initiated at an object terminal and printed at 
a printer work station. 

FIGS. 18A and 18B are processing and 
flowchart diagrams, respectively, for a modify op- 
eration which is conducted without additional scan- 
ning. 

FIGS. 19A and 19B are processing and 
flowchart diagrams, respectively, for a modify op- 
eration which is conducted with additional scan- 
ning. 

The invention relates to an object management 
and delivery system having multiple object-resolu- 
tion capability. 

In order to increase the clarity and understand- 
ing of the description of the invention, the following 
definitions are adopted for the purposes of the 
application: 

An "object" is defined as any stream of data 

bits. 

Digitized data, which are derived from signals 
resulting from, and related to, objects and which 
may be utilized in reproduction of the objects, are 
referred to as "object data". This object data may 
be stored or transmitted using magnetic, electronic 
or optical techniques and, further, transmission 
may be conducted in the digital or analog form. 

Object data related to a single or multi-page 
document will be referred to as a "record". 

Whenever possible, corresponding reference 
numerals will be used for corresponding compo- 
nents throughout the several drawing figures. 



is highly dependent upon hardware and software 
chosen to implement the disclosed host computing 
system and the object management and delivery 

w system. 

The term "object" was purposely given a com- 
prehensive definition so as not to limit the scope of 
the invention. The inventive object management 
and delivery system is particularly suited for use as 

75 an image storage/retrieval system wherein object 
data are more specifically "image data" which are 
derived from signals resulting from, and related to, 

electronic_scanning_of_documents r -and-which-may- 

be utilized in reproduction of images representative 

20 of the documents. The following discussions occa- 
sionally characterize the invention as an image 
storage/retrieval system, as such a characterization 
is the most convenient form for explanation and 
may prove helpful in developing a clear under- 

25 standing of the invention. 

In many organizations throughout the world, 
- both governmental and private, document handling 
represents a formidable task in terms of both time 
requirements and cost. The documents may be of 

30 current interest and/or purely of historic interest 
and the documents may contain information printed 
or typewritten by machine, printed or written by 
hand, or pictures, drawings and other forms of 
representations commonly referred to as 

as "graphics". It is very often necessary to access 
selected documents for various purposes within a 
short time from a large volume of documents. Not 
all of the information contained in the documents 
may be of importance, in addition, documents may 

40 be of greater or lesser degrees of importance, 
depending upon the type and contents of the docu- 
ments as well as the nature of the organization. 

As one exemplary environment, in applications 
such as the insurance industry where 

45 regional/branch offices for a single insurance com- 
pany or agency are often located widely about a 
country, each office has a need for being able to 
obtain a listing of documentation maintained in a 
given file associated with a particular customer and 

so to readiiy examine a copy of any one of the par- 
ticular documents so listed. In this way, each. insur- 
ance claims officer can be fully informed of the 
background situation involved with any transaction 
or any given claim being handled through his or 

55 any other office of the company. 

FIGS. 1 and 2 are architectural diagrams in- 
cluding the dual density digital image system of 
the present invention. 
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At an or gan izational _installa tion_depicted„gen- 



_5j_alLconnected_via_network_39._ 



erally by reference numeral 10 (FIG. 1), there is an 
object management and delivery system 12 
(hereinafter "OMDS") shown in conjunction with a 
host computing system 13 (hereinafter "HCS") 
genera l ly~r e pr e s e hting' a~co^ 



tern operating within the organizational installation 
10 independent of the image system 12 (i.e., the 
installation operating system may represent an op- 
erating system in existence before installation of 
the image system). 

The host operating system 13 may include, for 
example, a file management system 19 (hereinafter 
"FMS") which is connected to data terminals 18 
and which maintains an electronic data base (not 
shown) having work files containing data pertinent 
to a particular subject (e.g., an insurance customer 
"file)~DOe~to™^tbrage and" access time~limitations 
associated with such a system, the data base of 
the file management system 19 typically contained 
an index with abbreviated comments as to objects, 
e.g. hardcopy documents associated with that sub- 
ject. Without the object management and retrieval 
system of the present invention, a user would have 
to manually retrieve or request a stored hardcopy 
in order to view a representation of a desired 
document. 

Each of the data terminals 18 is part of a 
workstation 20 which further includes at least an 
image terminal 21. While in the presently preferred 
embodiment the data terminal 18 and image termi- 
nal 21 for each workstation are provided as dis- 
crete devices to segregate the operation of the 
operating system 13 (i.e., to allow the operating 
system to operate in the event of an image system 
failure), an embodiment is also envisioned where 
the data terminal and image terminal devices for 
each workstation 20 are incorporated into a single 
device. 

Each of the image terminals 21 is connected to 
a communication network 38 (e.g., a token ring 
network including a network controller) which is 
connected to an object storage and delivery man- 
ager 48 (hereinafter OSDM). 

The OSDM 48 is able to communicate with the 
file management system 19 regarding document 
registration, document retrieval and routing re- 
quests (all to be described below), and in response 
thereto is able to retrieve object data stored in an 
object storage and to provide this object data to 
one or more of the image terminals 21 through the 
communication network 38. In order to conduct 
object storage and retrieval tasks, the OSDM com- 
prises an object storage manager (OSM). The ob- 
ject storage comprises, for example, a magnetic 
disk DASD (Data Acquisition and Storage Device) 
50, 60, magnetic DASD controller 49, optical library 
52, back-up optical drive 53 and optical controller 



The hardware and software of the OMDS 12 
und operating system 13 at a given installation may 
be close together (e.g., in the same room) or 

5 widely disbursed (e.g., on different floors) as long 
as "t he Imp b ilan t~uunu nui nual i 6n~ Hnk~1'7 between 
the two is maintained. Further, while the organiza- 
tional installation 10, including the OMDS 12 and 
operating system 13, may be in a first city (e.g., 

to Washington, D.C.), installation 10a (FIG. 1) is an 
example of a installation which can be located quite 
a distance away from the first installation, e.g., in 
Los Angeles. Further, the invention is not limited 
and may be applied in multiple concurrent installa- 

;s tions, with each installation being able to retrieve 
object data from any other installation. For sake of 
simplicity and ease of discussion, only two installa- 



tions are shown. 

As examples of interaction between the two 

20 installations, file management system 19 can re- 
quest object data from OSDM 48a via communica- 
tions link 16. Likewise, file management processor 
19a can request object data from OSDM 48. An 
important aspect to realize is that, while there can 

25 be an exchange of record registration, record re- 
trieval and routing request information between the 
file management systems and the OSDM, object 
data are not transferred back to the requesting file 
management system, but instead must be routed 

30 to the requesting installation's local image terminal 
(e.g., 21) through the OSDM (e.g., 48) which is 
associated with the requesting installation. Thus, 
while the file management systems can request 
object data from a distant image system through 

35 the communication links 16 or 16a, the object data 
must be routed to the OSDM of the requesting 
installation through the communication link 15. 

In addition to the need for file management 
systems to request object data from remote image 

40 systems, frequently an OSDM may require retrieval 
of object data which it does not own (i.e., data 
which are not stored in it's associated object store, 
but are instead stored in the object store of a 
different image host processor (e.g., 48a)). In such 

45 a case, the OSDM is able to use a communication 
link 15 to request and retrieve needed object data. 
As the communication exchange is between two 
OSDMs, such a communication can be coined a 
"mirror" operation. 

so FIG. 2. depicts a single workstation 20 
(excluding a data terminal) and its connection over 
a network line 38 to the object host and storage 40. 
Although there is only a single workstation 20 de- 
picted, it should be apparent from FIG. 1 that there 

55 may be many workstations 20 connected in a local 
area network to a single object host and storage 40 
or to a plurality of object hosts and storages 40. 
Turning now to a more detailed description of 
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the block diagram of FIGS. 1 and 2, for greater 



detail on the management of the DASD 50 and 60 
and the optical storage 52 by the image host 
processor 48 please refer to the following copen- 
ding applications which are hereby incorporated by 
-rof o r e nce:- S e rial No , - 1 90 , 61 2, -fi l e d M a y-5 , -1988- 



not the subject of the invention. 

The workstatiorTimage terminaris~coliple'd"over 
a communication adapter 36 (FIG. 2 or 3) and the 
network line 38 to the object host and storage 40. 
s The communication adapter 36 may be, for exam- 
— pla,- an IBM-token ring adapter 



entitled "Batching Data Objects for Recording on 
Optical Disks"; Serial No. 190,739, filed May 5. 
1988, entitled "Method of Managing Data in a Data 
Storage Hierarchy and a Data Storage Hierarchy 
Therefore"; Serial No. 190.738. filed May 5, 1988. 
entitled "A Method of Managing a Media Library"; 
Serial No. 190,421, filed May 5. 1988, entitled "A 
Multi-Level Peripheral Data Storage Hierarchy with 
Independent Access to Ail Levels of the Hierar- 
chy"; and Serial No. 190,422, filed May 5, 1988, 
entitled "Data Storage Hierarchy and Method for 
~Managing~Data~Therein n ; 

The currently preferred data processing sys- 
tem shown in FIG. 1 will store and display objects 
in the following manner. Document input scanner 
22 is coupled through an adapter 22 (FIG. 3) to 
the system bus 37 of the workstation. The docu- 
ment input scanner 22 digitizes document images 
at a first resolution which, in this example, is a 200 
pel per inch resolution. In order to illustrate these 
image resolutions, an example is given in FiGS. 4 
and 5 of how the line A - B is depicted in a high 
resolution digitization of FIG. 4 and a lower resolu- 
tion digitization of FIG: 5. 

In FIG. 4, the line A - B is digitized into pel 
elements in a 16 x 16 matrix resulting in a total of 
256 bits for a bit plane representation of the image 
area. 

In FIG. 5, the resolution is cut in half so that 
the image area is divided into an 8 x 8 matrix, and 
64 bits are required for the bit plane representing 
the image area. 

Image display unit 30 is coupled to the work- 
station for displaying a digitized object or docu- 
ment image at the second lower resolution which in 
this example is 100 pels and is illustrated by the 
lower resolution image in FIG. 5. 

In addition to the first high resolution and sec- 
ond lower resolution digitization discussed above, 
in a presently preferred embodiment, printer 46 is 
coupled to the workstation for printing digitized 
objects and document images at a third resolution 
of 300 pels per inch. This resolution is greater than 
the input resolution from the document scanner 22, 
which is 200 pels per inch. As will be appreciated 
by one skilled in the art, the 300 pel per inch 
printing resolution has been adopted to advanta- 
geously render the preferred embodiment consis- 
tent with current printing standards. The processing 
and adaptation of originally scanned 200 pel per 
inch object or image data into 300 pel per inch 
data for printing are well known in the art and are 



Looking at the workstation 20 in more detail, a 
higher resolution bit plane memory 24 has its input 
coupled to the document scanner 22 for receiving 

m a digitized document image at the first, higher 
resolution of 200 pels, such as that represented in 
FIG. 4. In the hardware depiction of the workstation 
in FIG. 3, the system memory 41 for the work- 
station 20 can be envisioned as being partitioned 

is into several instruction code regions and several 
storage or buffer regions. One of the storage re- 
gions in memory 41 is set aside for the high 

resolution-bit-plane-24^ln-practice-these-several 

instruction code regions and buffer regions may be 

20 provided in a single memory means or several 
memory means. 

Also included in the workstation 20 is a higher 
resolution object compression unit 32 having an 
input coupled to the higher resolution bit plane 

25 memory 24 and an output coupled through the 
compressed higher resolution data buffer 34, and 
thus this output is available to the communication 
adapter 36 and the line 38 connected to the object 
host processor 48 in the object host and storage 

30 40. The compression unit 32 compresses the first 
or higher resolution digitized object or document 
image such as that depicted in FIG. 4, and outputs 
a first compressed object record to the object host 
computer 48 for storage. 

35 Object or image compression can be per- 
formed in a variety of ways which are well known in 
the art. A simple approach applying run length 
encoding principles can be explained to compress 
an exemplary digitized bit plane image. For exam- 

40 pie in FIG. 4, the line A - B has been digitized in 
the bit plane 24 into an array of black and white 
pels, where each white pel is represented by a 
zero binary value, and each black pel Is repre- 
sented by a one binary value, for a total of 256 bits 

45 in the bit plane 24. A simple run length encoding 
technique always starts with a white pel in a row, 
and then the number of consecutive white pels 
along the row is counted. For a 16 x 16 matrix, 
there will not be more than sixteen consecutive 

so pels having the same black or white value; there- 
fore, a four-bit representation for each run can be 
used. 

Every time ,the color of the pel changes from 
black to white, a next four-bit expression is used to 
55 count the number of consecutive next pels of the 
same color. For example, in the first row of the bit 
plane 24 of FIG. 4, the first two pels starting at the 
left side are white; therefore, a first four-bit value of 
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-G010-can-be-used-to-run-length-encode-the-first- 
two pels. The third pel in the first row is a black 
pel, and there is only a single black pel. Therefore, 
the next four-bit expression for the row is 0001 , the 

, number of black pels equaling one. „ 



Lower-resolution-object-compression-unit-56- 

has an input coupled to the lower resolution bit 
plane memory 28, and an output coupled through 
the compressed lower resolution data buffer 58 to 

„5 the_ communication, adapter 36_and thus Jthe_net-_ 



Since there will always be, at most, sixteen 
pels for a row, the technique for this exemplary run 
length encoding stops generating four-bit run 
length coding numbers so that the last consecutive 
run of like colored pels is not numbered at all, and 
the difference from the value of sixteen gives the 
remaining run length and coded value for the final 
number of pels. In this case, its thirteen white pels 
complete the first row in FIG. 4. Thus, compressed 
higher resolution data such as that shown in FIG. 4 
are generated by the object compression unit 32 
_and_stored_in. thebuffer_34. 



In the object host and storage 40, a first object 
storage unit 50 is a magnetic disk DASD (Data 
Acquisition and Storage Device) which is coupled 
to the image object host processor 48 for storing 
compressed records of objects or images digitized 
at the first, high resolution such as that shown in 
FIG. 4. The object host processor 48 controls the 
storing of the first, higher resolution compressed 
image records in the compressed higher resolution 
data storage 50. 

Further in the workstation 20, a resolution 
modification unit 26 has an "input coupled to the 
higher resolution bit plane memory 24, for reducing 
the resolution of the first digitized object or docu- 
ment image corresponding, for example to that 
shown in FIG. 4 to a second, lower resolution 
object or image, such as that shown, for example 
in FIG. 5. This lower resolution is then outputted as 
a second resolution digitized document object to 
the lower resolution bit plane memory 28. As can 
be seen in FIG. 3, resolution modification unit 26 
can be embodied in the memory 41 as a resolution 
modification code 26' which can be executed by 
the CPU 35 in the workstation. The resolution 
modification unit operates to make the transition 
from a high resolution bit plane representation such 
as that shown in FIG. 4, to the bit plane representa- 
tion shown in FIG. 5, by converting from a higher 
resolution matrix (e.g., a 16 x 16 matrix) down to a 
lower resolution matrix (e.g., an 8 x 8 matrix). 

The workstation 20 further includes a lower 
resolution bit plane memory 20, which has an input 
coupled to the resolution modification unit 26, for 
receiving the second, lower resolution digitized ob- 
ject or document image. As is seen in FIG. 3, the 
lower resolution bit plane 28 can also be embodied 
as a partitioned portion of the memory 41 . 

The image display unit 30 has an input, coup- 
led to the lower resolution bit plane memory 28, for 
receiving the second, lower resolution digitized ob- 
ject or document image for display. 



work line 38 connected to the object host proces- 
sor 48 of the object host and storage 40. The 
object compression unit 56 compresses the sec- 
ond, lower resolution digitized object document or 

ro image, and outputs a second object record to the 
object host computer 48 for storage. The second, 
lower compressed object record is smaller in size 
than the first, higher compressed object record, as 
can be seen, for example, in a comparison of FIGS. 

is 4 and 5, where the compressed higher resolution 
data from the run length encoding operation oc- 

_cupies„128_bits l _and_the_run_length_encc<ied_ver=_ 

sion of the compressed lower resolution data oc- 
cupies 48 bits. In accordance with the invention, 

20 whenever a lower resolution image is of sufficient 
resolution for a given application, it is preferable to 
access the second, iower resolution compressed 
object data from the object storage media and to 
transmit this data over the network since lower 

25 resolution object data (having lesser amounts of 
data than high resolution object data) require less 
of an access time and impose less of a traffic load 
on the network. 

The object host and storage 40 also includes a 

30 second storage unit 60 in the form of a magnetic 
disk DASD (Data Acquisition and Storage Device) 
which is coupled to the object host processor 48 
for storing compressed records of objects or im- 
ages digitized at the second, lower resolution cor- 

35 responding, for example, to FIG. 5. The object host 
processor 48 controls the storage of the second, 
lower resolution compressed object records in the 
second image storage unit 60. 

Higher resolution decompression unit 42 has 

40 an input coupled from the network line 38 through 
the communication adapter 36 and the compressed 
higher resolution data buffer 34, for receiving and 
decompressing the first higher resolution compres- 
sed objects, and for decompressing the first object 

45 records from the first object storage device 50, to 
restore the first, higher resolution digitized object or 
document Image. Referring to FIG. 3, the higher 
resolution data decompression unit can be em- 
bodied as a part of the image 

so compression/decompression processor 39 which is 
connected over the system bus to the CPU 35 in 
the workstation 20. Further, the compression units 
32 and 56 and the decompression units 42 and 62 
in the workstation 20 can ail be embodied in the 

55 same image compression/decompression proces- 
sor 39. An example of such a processor is de- 
scribed in the U. S. Patent 4,610,027, by Anderson, 
et af., "Method for Converting a Bit Map of an 
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Image to a Run Length or Run End Representa- 



higher resolution. 



tion," assigned to the InternationirBusiness Ma 1 " 
chines Corporation, and incorporated herein by ref- 
erence. 

It is also possible to have the compression and 
riftmmpression- algorithms.— represented -by— the- 



As records~become less active and~~dT"less 
interest, the presently preferred embodiment con- 
templates a transfer of these records to storage in 
5 the permanent third object storage device 52. The 
storage-operation- for a-tran sfer-from active-toper-- 



units 32, 56, 42 and 62, embodied in an executable 
code which is stored, for example, in the applica- 
tion program 43 in the memory 41 of the work- 
station 20. 

An object scaling unit 44 has an input coupled 
to the higher resolution object decompression unit 
42, and converts the first, higher resolution digitiz- 
ed object into a third resolution digitized document 
object having a third resolution which, in this exam- 
ple, is 300 pels per inch. This third resolution is 
adapted for the printer 46 which has an input 
-coupled-through-the-printer-adapter-46— to-the- 
object scaling unit 44. The printer is capable of 
printing a high resolution image, and the scaling 
unit 44 will convert the higher resolution 200 pel 
image, which has been accessed from the object 
host and storage 40, into the appropriate resolution 
for driving the printer 46. Reference to FIG. 2 will 
show that the object scaling unit 44 can be em- 
bodied in an executable code which is the object 
scaling code 44 stored in the memory 41 and 
executed by the CPU 35. 

The resulting system reduces communications 
traffic on the network because smaller compressed 
data records are available for transmission for low 
resolution operations. Access time for storing and 
reading lower resolution compressed data records 
is also reduced; however, because of the image 
system's concurrent ability also to maintain high 
resolution object data in the high resolution mag- 
netic disk DASD 50 or the permanent optical stor- 
age 52 (discussed ahead), this lower traffic and 
faster access time are obtained without sacrificing 
the availability of high resolution compressed data 
records which are occasionally needed for the high 
resolution printer and other high resolution oper- 
ations. 

Magnetic disk DASD storage 50 and 60 repre- 
sents a preferable storage facility where a lower 
resolution record is being maintained, or, where a 
record is "active" in the sense that the record has 
recently been entered into the OMDS and/or the 
record is one which will likely be requested -or 
modified soon. However, magnetic disk DASD stor- 
age is typically limited in terms of storage space. 

For more permanent image data storage, a 
third object storage unit 52 can be included which, 
for example, can be a high capacity optical storage 
device suitable for the permanent storage of digitiz- 
ed objects. The third image storage device 52 is 
coupled to the object host processor 48 and stores 
compressed records of object digitized at the first, 



manent storage is illustrated by the flow diagram of 
FIG. 6. 

The host processor 48 will transfer the first, 

to higher resolution compressed records from the first 
storage DASD 50 to the third optical storage device 
52 after a predetermined aging period, for example, 
30 days. This aging period enables systems' oper- 
ators to have current digital object records on hand 

15 on the DASD storage device 50 over a predeter- 
mined interval of time, such as 30 days, during 
which operations with the stored objects will usu- 

ally-be-completed— During-the-predetermined-pe- 

riod, the object host computer 48, in response to 

20 requests from the command input unit 25 at a 
workstation 20, will selectively access a first, high 
resolution compressed object record from the first 
storage DASD 50. However, after the expiration of 
the predetermined period, in this example, 30 days, 

25 the object host processor 48 will selectively access 
the first high resolution compressed image record 
from the third storage, or the optical storage device 
52. The host processor 48 will be able to determine 
an elapsed period associated with an object by 

30 deriving this information from chronological digits 
of a permanent object name (discussed ahead) 
associated with the record. 

The host processor 48 will discard the second, 
lower resolution compressed object records, such 

35 as the exemplary record shown in FIG. 5, from the 
second storage DASD 60 after the expiration of the 
predetermined period (e.g., 30 days). Thereafter, if 
a request is made at the command input unit 25 to 
retrieve a copy of a digitized object for display on 

40 the display device 30, the following operations 
would be followed. 

Since the lower resolution (e.g., the 100 pel per 
inch) is no longer stored in the object host and 
storage 40, the host processor 48 will access high- 

45 er resolution (e.g., the 200 pel per inch) object data 
record of the digitized object from the permanent 
optical storage 52. The compressed high resolution 
record will be decompressed in the high resolution 
data decompression unit 42 of the workstation 20. 

so The resulting digitized high resolution object will be 
directed over line 54 to the higher resolution bit 
plane memory 24 where it will be applied to the 
resolution modification unit 26, thereby resulting in 
a lower resolution object which is applied to the 

55 lower resolution bit plane memory 28 for applica- 
tion to the image display 30. This operation is 
depicted in the flow diagram of FIG. 7 for the 
display operation. The dual density capability of 
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-theHmage-retrieval/storage-systemHs-further-ex-- 
plained in co-pending application "Dual Density 
Digital Image System". 

In prior art systems, the operations of a host 
computing system and an image systerrLare jypi- 



printing)-on-the-document-1— The-temporary-docu-- 

ment ID may be posted on a non-important area 
(e.g., on a back-side), of the document, on simply 
the first page or, for extra safety, on each page of 

_s the document.^ _ 



cally integrated such that a critical breakdown in 
the operation of the image system also results in a 
disadvantageous breakdown of the host computing 
system. 

An important feature to note is that the inven- 
tion has produced a method which allows an object 
management and delivery (OMDS) system to per- 
form desired object-related requests with only a 
modicum of interaction between the operations of a 
host computing system (e.g., the previously dis- 
cussed file management system) and the OMDS. 
For the purposes of this application,_the„term_ 
"modicum of interaction" is defined as a small or 
moderate amount of interaction. Several interac- 
tions have been previously mentioned. A non-ex- 
haustive list of typical interactions include: object- 
related requests transferred from the FMS to the 
OMDS; object registration data transferred from the 
OMDS to notify the FMS that an object record has 
been stored; and/or error data transferred from the 
OMDS to notify the FMS when the OMDS encoun- 
ters and error in trying to perform an object opera- 
tion request by the FMS. 

The substantially discrete operation or the in- 
ventive OMDS will be more fully appreciated after * 
a discussion of the several object-related oper- 
ations discussed below with reference to FIGS. 6- 
19. 

Throughout these figures and the discussion to 
follow, method steps will be associated with refer- 
ence numerals beginning with an "S", and pro- 
cessing paths or locations will be associated with 
reference numerals beginning with a n P". When- 
ever possible, a processing path or location result- 
ing from and corresponding to a particular method 
step will be assigned the same numerical trailer, 
e.g.. "S101" and n P101 n . 

A "capture" operation will be described with 
initial reference to FIGS. 12A an 12B. 

At a step S1 , a single or multi-page document 
1 arrives at the organizational installation, e.g., at a 
mailroom. In step S2, a request is sent from a 
workstation (hereinafter "WS") data terminal to the 
file management system (hereinafter "FMS") via 
processing path P2 for a temporary document ID. 
A temporary document ID can be any type of ID 
number (e.g., "ABC" or any other randomly gen- 
erated number), as long as a different temporary 
document ID is assigned upon each request to 
distinguish different respective documents. In step 
S3, a temporary document ID is assigned by the 
FMS and returned via processing path P3 and is 
posted (e.g., via manual handwriting or machine 



In a step S4, the FMS generates and sends to 
the OMDS associated with the requesting WS data 
terminal, a permanent document name coordinated 
with the name with the temporary document I.D. 

io currently associated with the document. The re- 
ceipt and storage of the permanent document 
name in the OMDS act as an authorization to allow 
input scanning of a document having associated 
temporary document ID. 

76 A presently preferred object-naming convention 
is illustrated in FIG. 10. 

AJirst_name_portion_6_generated-by_the_FMS- 

comprises: application digits "UF" specifying an 
application (e.g., insurance division, parking ticket 

20 division, etc.) to which the object is relevant; state 
code "ss" specifying a geographical or other loca- 
tion data; object number "CccUccccccc" including 
a uniqueness number W U"; object version number 
"V" which would typically be some default value 

25 (e.g., "0" unless a later version of an object is 
created later in same day) and chronologic digits 
"mrnddyy" specifying the date the object was re- 
ceived. 

In step S5, the document 1 is manually trans- 

30 ported as indicated by processing path P5 to a WS 
document scanner station. It should be noted that 
this transport operation may occur over a substan- 
tial period of time (e.g., hours, days, weeks) and 
typically will result in the document being trans- 

35 ported to a WS document scanner station which is 
remote from the WS data terminal used to original- 
ly request the temporary document ID. 

In step S6, the temporary document ID trans- 
posed on the document is entered into the image 

40 terminal 21 and is sent as indicated by processing 
path P6 to the OSDM to verify correctness and 
storage authorization. 

In step S7, the OSDM returns an indication 
represented by processing path P7 of whether or 

45 not the temporary document ID entered is invalid 
or valid. If invalid, the OSDM reports an error and 
processing jumps to step S6 Jo allow a user to 
reenter the temporary document ID. (Alternatively, 
processing could jump to END.) If valid, the OSDM 

so returns a verification indicating that scanning is 
authorized for that document. 

In step S8, the document is scanned via scan- 
ner 22, the image data quality is verified by an 
operator viewing an image monitor or printout of 

55 the document, and the image data is sent to the 
OSDM. 

In step S9, the OSDM stores the object data as 
a record using the permanent document name. As 
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the record is "active" in the sense that it was 

^ec~ently~ihput1nto~the~system 
hood that the record may be requested or modi- 
fied, in a preferred embodiment the record would 
be stored in magnetic DASD 50 or 60 to accom- 

-modate prompt retrievaLand/or_modification._ 



object data record has been stored. 
FIG-6-is-a-data-flow-diagram-showing-further- 

details of the capture or store operation. 

At this point, it is useful to discuss the storage 
s management of the image system. As discussed 
„ previously., the Jmage„system JL2„comprjs_es 



While a first name portion 6 (discussed above) 
is generated by the FMS, a second name portion 7 
(FIG. 10) is generated by the OSDM. First digital 
"t" indicates object type, for example, one version 
of the digit "t" might indicate that the object is of 
legal significance (e.g., customer correspondence). 
Second digit V indicates copy type, e.g., that 
scanning was conducted from an original document 
or a photocopy. Finally, digits "pp" indicate the 
resolution (e.g., 100 pels per inch or 200 pels per 
inch) of the object data contained in the record. 

ln-Step-S10,-StepS-S6-tO-S10_are_repeated_if_a„ 

capture is also to be conducted at a different 
resolution. 

In a normal case, storage for a document in a 
capture operation is conducted to store both a low 
resolution (e.g., a 100 pel per inch) record and a 
high resolution (e.g., a 200 pel per inch) record. 

The low resolution record is stored because an 
object will typically be an active object for a short 
period of time thereafter (e.g., 30 days), and the 
low resolution record will represent an alternative 
where data retrieval and network traffic are mini- 
mized. Note that retrieval and transmission of a low 
resolution record is especially preferred where an 
object image is to be displayed on the preferred 
100 pel per inch image monitor. 

The high resolution record is stored to provide 
sufficient object data which can be used to perform 
a high-quantity printing reproduction of the original 
document, and also, for the expected permanent 
storage of the object record as a high resolution 
record. 

As will be appreciated by one skilled in the 
computer art, the inventive OMDS can be con- 
structed to allow an operator to override this default 
situation. 

Finally, in step S11, the OMDS notifies the 
FMS that an object data record associated with that 
permanent object name has been stored. The FMS 
can be constructed to thus update a listing of 
documentation of a subject workfile associated with 
said object. Operators at workstations 20 would 
thus be able to access an image reproduction of 
the object, whether by display on an image monitor 
or by printing. 

An important aspect to note is that there is no 
object data transfer from the OMDS to the FMS. 
i.e., communication from the OMDS to the FMS 
occurs only when the OMDS encounters an error is 
trying to perform an operation requested by the 
FMS. or when the OMDS notifies the FMS that an 



object storage which includes low resolution DASD 
60, high resolution DASD 50 and optical storage 
52. In performing any record storage or retrieval 

to operation, the IHP could store records at random or 
at the next sequential storage location and then 
search the index of each magnetic disk and optical 
disk to retrieve an object. However, in order to 
increase operating speed efficiency, the preferred 

15 embodiment of the invention makes use of the 
permanent object name and storage management 
rules (discussed below) to determine the appro- 
^___priate„(for_storage)_or_likely_(for_retrieval)_place_of_ 
record storage. 

20 For example, the OMDS can interrogate the 
state code digits "SS" of the object name (FIG. '10) 
to determine whether object storage is in the cur- 
rent (i.e., local) object storage or at a remote object 
storage). 

25 Further, in the OMDS of the preferred embodi- 
ment, records are typically maintained in magnetic 
disk DASD 50 or 60 for a period of at least 30 
days. Thus, if an interrogation of the chronological 
digits "mmddyy" (FIG. 10) of the object name 

30 reveals that a period of approximately 30 days or 
fewer has passed since the object was received, 
the OMDS can make an assumption and make an 
initial attempt to retrieve the desired object from, 
magnetic disk DASD. Upon failure of this attempt, 

35 the OMDS could then attempt retrieval from optical 
storage. 

If the magnetic disk and optical disk memories 
are further partitioned and records are stored in 
these partitions according to object type, copy type 
40 and resolution, the "txpp" digits of the record's 
object name can further be used to increase the 
operating speed efficiency of storage and retrieval 
operation. 

As mentioned previously, a record may be 
45 stored in different storage apparatus during dif- 
ferent periods of the record's life. Further, it may 
be desired to apply different storage rules and life 
span rules to different types of records. 

A "prefetch" operation will be described with 
so initial reference to FIGS. 13A and 13B. 

A "prefetch" operation is useful in situations 
where it is known that a particular record will be 
requested within a short period of time. As an 
example of such a situation, an insurance business 
55 environment may have a set-up where correspon- 
dence inquires are followed up with a bank of 
telephone operators making telephone solicitations 
to potential customers. Thus, correspondence in- 
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quiries_could_be— scanned— and— converted— into- 
records when received, and the FMS could then 
maintain a work queue of outstanding inquiries and 
periodically make a request for a "prefetch" of 
records pertaining to telephone solicitations which 



Jn-step-S33,-a-retrieval-command-is-built-by-the 



"are to "be conducted shortly. 

In step S20, the FMS selects an object record 
from the work queue or a request is made from a 
WS data terminal. In a step S21 t a prefetch com- 
mand is built and transferred to the OMDS likely to 
own the object data or record for the desired 
document. (Note that the state code digits "SS" of 
the document name (FIG. 10) may prove useful in 
a determination of whether a local or remote stor- 
age is suspected.) If the OMDS 12 is determined 
likely to own the record, the prefetch command is 
transferred via processing path P21a. In contrast, if 



OSDM, the desired object data record is retrieved 
from the appropriate storage apparatus, and the 
object data record is transferred to the OSDM 

s associated with the requesting WS data terminal Jt 
should be notea tnat ir a remote UMDFS owns the 
object data record for the desired document, 
dashed (— ) processing paths P33a and P33b 
would be required. 

w in step S34, the object data record is trans- 
ferred as indicated by processing path P34 from 
the OSDM to the WS image terminal for display. 

FIG. 7 is a data flow diagram showing further 
details of the display operation. 

75 Several print operations requests are available 

in the preferred embodiment, i.e., a print operation 
may be requested by a WS data terminal, a WS 



a remote OMDS 12a is determined likely to own 
the record, the prefetch command is transferred via 
dashed (— ) processing path P21b. 

In step S22, a retrieval command is built and 
sent to the appropriate storage facility by the 
OSDM a copy of the desired object data record is 
retrieved, and the copy is transferred to the OSDM 
associated with the requesting FMS or WS data 
terminal. Note that if a remote OMDS owns the 
image data record for the desired object, oper- 
ations utilizing dashed (— ) processing paths P22a 
and P22b would be required. If the prefetch com- 
mand was initially transferred to the remote OMDS, 
operations utilizing only dashed (— ) processing 
paths P21b and P22b would be required. 

In step S23, the OSDM associated with the 
requesting FMS or WS data terminal stores a copy 
of the object data record for the expected future 
access. The object data record will be stored in the 
OSDM if it contains sufficient storage facilities. 
Otherwise, the object data record will be stored in 
the magnetic disk DASD 50 or 60. 

A "display" operation will be described with 
initial reference to FIGS. 14A and 14B. 

In step S30, an object display request is made 
by an operator at a WS data terminal as indicated 
by processing path P30. In step S31, the FMS 
receives the request and (as indicated by the pro- 
cessing operation P31) builds a display command. 
In order to specify the desired record for display, 
part of the display command will contain an object 
name portion 6 such as that illustrated in FIG. 10 In 
step S32, the FMS display command is asyn- 
chronously transferred as indicated by processing 
path P32 to the OSDM associated with the request- 
ing WS data terminal. An important aspect to note 
is that no response will be returned from the 
OSDM to the FMS, i.e., communication from the 
OSDM to the FMS occurs only when the OSDM 
encounters an error in trying to perform the display 
operation requested by the FMS. 
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image terminal not having a printer apparatus, and 
a WS image terminal having a printer apparatus. 
The print operations for each type of request will 
be separately discussed below. 

A "print from data terminal" operation will be 
described with initial reference to FIGS. 15A and 
15B. 

In step S40, an object print request is made by 
an operator at a WS data terminal as indicated by 
processing path P40. In step S41, the FMS re- 
ceives the request and (as indicated by the pro- 
cessing operation P41) builds a print command. In 
order to specify the desired record for display, part 
of the print command will contain an object name 
portion 6 such as that indicated in FIG. 10. In step 
S42, the FMS print command is asynchronously 
transferred as indicated by processing path P42 to 
the OSDM associated with the requesting WS data 
terminal. An important aspect to note is that no 
response will be returned from the OSDM to the 
FMS, i.e., communication from the OSDM to the 
FMS occurs only when the OSDM encounters an 
error in trying to perform the display operation 
requested by the FMS. 

In step S43, a retrieval command is built by the 
OSDM, the desired object data record is retrieved 
from the appropriate storage apparatus, and the 
object data record is transferred to the IHP asso- 
ciated with the subject printer which is to repro- 
duce the desired object from the object data 
record. It should be noted that if a remote OMDS 
owns the object data record for the desired object, 
dashed (--) processing paths P43a and P43b 
would be requ-reo. 

in step S44, a print command is transferred as 
Indicated by processing path P44, with object data 
through the printer work station (PWS) image ter- 
minal to the printer for printing. In a real-world 
environment, it is often not cost effective to provide 
each WS with a dedicated printer. Thus, FIG. 15A 
was purposefully constructed to illustrate that the 
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subject printer might be at a WS which is distant 
-from-the-requesttng-WS; 

A "print displayed page" operation is used in 
situations where an operator, viewing an object 
image at an image monitor PWS, desires to print 
the displayed, page. J3eferenceJs_made-tO-FIGS.~ 



If the WS image terminal contains an object 



data record at a resolution sufficient for printing 
(i.e., a 200 pel per inch record which can be 
expanded to a 300 pel per inch record), the object 
5 data record is transferred to the OSDM. Processing 
then j i im ps tn a Qfpp ftfi4 — 



16A and 16B. 

In step S50, a print request is made by an 
operator at a PWS image terminal whereupon, in a 
step S51, the PWS image terminal builds a print w 
command. 

If the PWS image terminal contains an object 
data record at a resolution sufficient for printing 
(i.e., a 200 pel per inch record which can be 
expanded to a 300 pel per inch record), the print 1$ 
command and object data are transferred to the 
PWS printer. Processing then continues with step 
S5 5. . 

If the PWS image terminal does not contain an 
object data record at a resolution sufficient for 20 
printing, in step S52b the print command is trans- 
ferred via processing path P52b to the OSDM 
associated with the subject printer. In order to 
specify the desired object for display, part of the 
print command will contain an object name portion 25 
6 such as that indicated in FIG. 10. 

In step S53 t a retrieval command is built by the 
IHP, the desired object data record is retrieved 
from the appropriate storage apparatus, and the 
object data record is transferred to the OSDM 30 
associated with the subject printer which is. to re- 
produce the desired object from the object data 
record. It should be noted that, if a remote OMDS 
owns the object data record for the desired object, 
dashed (— ) processing paths P53a and P53b 35 
would be required. 

In step S54, a print command is transferred as 
indicated by processing path P54, with object data 
through the PWS image terminal to the printer for 
printing. 40 

Finally, in step S55, any printing errors are 
reported to the PWS image terminal originating the 
print request. 

As mentioned previously, in a real-world envi- 
ronment, it is often not cost effective to provide 45 
each WS with its own dedicated printer. A "print 
displayed page to printer workstation" operation is 
used in situations where an operator, viewing an 
object image at a WS, desires to print the dis- 
played page to a PWS which services the print so 
requests of that WS. Reference is made to FIGS. 
17Aand17B. 

In step S60, a print request is made by an 
operator at a WS image terminal whereupon, in a 
step S61, the WS image terminal builds a print 55 
command. In step S62, the print command is trans- 
ferred as indicated by processing path P62 to the 
OSDM associated with the subject PWS printer. 



If the WS image terminal does not contain an 
object data record at a resolution sufficient for 
printing, in step 63b a retrieval command is built by 
the OSDM, the desired object data record is re- 
trieved from the appropriate storage apparatus, and 
the object data record is transferred to the OSDM 
associated with the subject PWS printer. It should 
be noted that, if a remote OMDS owns the object 
data record for the desired object, dashed (— ) 
processing paths P63b and P63c would be re- 
quired. 

ln-step S64ra print command is'transfefred, as 

indicated by processing path P64, with object data 
through the PWS image terminal to the printer for 
printing. 

Finally, in step S65, any printing errors are 
reported to the WS image terminal originating the 
print request. 

FIG. 9 is a data flow diagram showing further 
details of a print operation. 

Several modify operations are available in the 
preferred embodiment, i.e., a modify operation may 
be requested to be performed without additional 
scanning, or to be performed with additional scan- 
ning. The operations for each type of modify re- 
quest will be separately discussed below. 

A "modify without scanning" operation is used 
in situations where, for example, a object must be 
modified by a deletion of excessive or extraneous 
pages or materials. Reference is made to FIGS. 
18Aand18B. 

In step S70, a modify request is made as 
indicated by processing path P70 by an operator at 
a WS image terminal, whereupon, in a step S71, 
the FMS builds a modify command, in order to 
specify the desired object for modification, part of 
the modify command will contain an object name 
portion 6 such as indicated in FIG. 10, 

In step S72, the FMS modify command is 
asynchronously transferred, as indicated by pro- 
cessing path P72, to the OSDM associated with the 
requesting WS data terminal. An important aspect 
to note is that no response will be returned from 
the OSDM to the FMS, i.e., communication from 
the OSDM to the FMS occurs only when the 
OSDM encounters an error in trying to perform the 
modify operation or when the OSDM sends an 
acknowledgement that a modified object data 
record has been stored. 

In step S73, a retrieval command is built by the 
IHP, the desired object data record is retrieved 
from the appropriate storage apparatus, and the 
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object_data„record_is_transferred— to-the— OSDM- 
associated with the requesting WS data terminal. It 
should be noted that, if a remote OMDS owns the 
object data record for the desired object dashed 
(— )■ processing paths P73a and P73b would J)e_ 



will~be-returned-from-the-0SDM-to-the-FMSH;e., 

communication from the OSDM to the FMS occurs 
only when the OSDM encounters an error in trying 
to perform the modify operation or when the OSDM 

JL_ _sends_a n acknowledgement that a mpdified„object . 
data record has been stored. 



""required 

In step S74, the object data record is trans- 
ferred, as indicated by processing path P74, from 
the OSDM to the WS image terminal for modifica- 
tion. 

In step S75. the desired modification is per- 
formed (e.g., the deletion of extraneous pages) at 
the WS image terminal and is transferred back to 
the IHP with a store command, whereupon, in a 
step S76, the modified object data record is stored. 
If the object record has been subsequently modi- 
fied during the sam e day it was initiall y entered 



into the system, or is modified several times in the 
same day, this will be reflected in the version digit 
rt V" of the object name (See FIG. 10). 

In step S77, the OSDM sends acknowledge- 
ment of the stored object data record to the WS 
image terminal. In step S78, steps S74 to S78 are 
repeated if an object modify operation is to also be 
conducted at a different resolution, e.g., an opera- 
tion may have modified a 100 pel per Inch record 
and wish to modify the corresponding 200 pel per 
inch record. 

Finally, at step S79, the OSDM notifies the 
FMS that a modified object data record has been 
stored. Operators at workstations would then be 
able to access a reproduction of the modified ob- 
ject; whether it be by display or an image monitor 
or by printing. 

A "modify with scanning" operation is used in 
situations where, for example, a object must be 
modified by an addition of new pages or materials. 
Reference is made to FIGS. 19A and 19B. 

In step S80 and S81, a mcdify request is made 
as indicated by processing page P81 by an oper- 
ator at a WS image terminal to signal that new 
object pages are to be added to an object data 
record, whereupon, in a step S82 a temporary 
object ID is returned by the FMS and is posted on 
the object pages either by manual handwriting or 
machine printing. In a step S83, the modify com- 
mand is built by the FMS and the FMS modify 
command is asynchronously transferred as indi- 
cated by processing path P72 to the OSDM asso- 
ciated with the requesting WS data terminal. In 
order to specify the desired record for modification, 
part of the modify command wilt contain an object 
name portion 6 such as that indicted in FIG. 10. 
The temporary object ID wilt also be transferred 
and associated with the modify command. The 
storage of the above in the OSDM acts to flag a 
modification authorization. 

An important aspect to note is that no response 



In step S84, the new object pages Z are man- 
ually transported, as indicated by the processing 
path P84 to the WS document scanner station. It 
10 should be noted that this transport operation may 
occur over a substantial period of time (e.g., hours, 
days, weeks) and typically will result in the object 
being transported to a WS document scanner 
which is remote from the WS data terminal used to 
75 originally request the temporary object ID. 

in step S85, the temporary object ID trans- 
posed o n_the_new„pages_is^enteredjnto-the-image 



terminal and is sent, as indicated by processing 
path P85, to the OSDM to verify correctness and 

20 storage authorization. 

In step S86, the OSDM returns an indication 
represented by processing path P86 of whether or 
not the temporary object ID entered is invalid or 
valid, if invalid, the OSDM reports an error and 

25 processing jumps to step S85 to allow a user to 
reenter the temporary object ID. (Alternatively, pro- 
cessing could jump to END.) If valid, the OSDM 
returns a verification indicating that scanning is 
autfiorized for that object. 

30 In step S87, a retrieval command is built by the 
OSDM, the desired object data record is retrieved 
from the appropriate storage apparatus, and the 
object data record is transferred to the OSDM 
associated with the requesting WS data terminal. It 

as should be noted that, if a remote OMDS owns the 
object data record for the desired object, dashed 
(— ) processing paths P87a and P87b would be 
required. 

■ in step S88, the object data record is trans- 

40 ferred the modified object data record is stored. If 
the object record has been modified subsequently 
during the same day it was initially entered into the 
system, or is modified several times in the same 
day, this will be reflected in the version digit "V" of 

45 the object name (See FIG. 10). 

In step S91, the OSDM sends acknowledge- 
ment of the stored object data record to the WS 
image terminal. In step S92, steps S87 to S92 are 
repeated \l an object document modify operation is 

50 to also be conducted at a different resolution, e.g., 
an operation may have modified a 100 pel per inch 
record and wish to modify the corresponding 200 
pel per inch record. 

Finally, at step S93, the OSDM notifies the 

55 FMS that a modified object data record has been 
stored. Operators at workstations would then be 
able to access an reproduction of the modified 
object, whether it be by display on an image moni- 
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tor or by printing. 



transferring steps further comprise the steps of: 



ArTimportlnt aspecHo^note"is"triarthe original" 
digitized record representing an object is never 
deleted from the optical storage unit 52, but there 
is created a new modified assemblage of digitized 
Jmages-which reflects-the modification 



retrieving temporary object identification characters 
from said host computing means (13), and posting 
said characters onto an object which is to be 
5 scanned; 

generating- a pftrmanft nt-nhjart -nama in sairf hnst- 



FIG. 8 is a data flow diagram showing further 
details of a modify operation. 

The resulting system reduces communications 
traffic on the network because of the smaller com- 
pressed data records which are transmitted for the 
low resolution operations. Access times for storing 
and reading the lower resolution compressed data 
records are also reduced; however, this lower traf- 
fic and faster access time are obtained without 
sacrificing the availability of high resolution com- 
pressed data records which are less frequently 
-needed-for-printing-operations-and-otherhigh-reso— 
lution operations. 

Although the invention has been described with 
reference to a specific preferred embodiment, this 
description Is not meant to be construed in a 
limiting sense. Various modifications of the dis- 
closed embodiment as well as alternative embodi- 
ments of the invention will become apparent to 
persons skilled in the art upon reference to the 
description of the invention. It is therefore con- 
templated that the appended claims will cover any 
such modifications or embodiments that fall within 
the true scope of the invention. 



Claims 

1. In a data processing system for storing a 
plurality of electronic object data records, and dis- 
playing and reproducing a desired object using 
said data records, said data processing system 
comprising host computing means (13) including 
data terminal means (18), and an object manage- 
ment and delivery system (12) having object man- 
agement means (48), memory storage means 
(50,60,52,53), image terminal means (21 ) and scan- 
ner means (22), a method which allows said data 
processing system to perform a desired object- 
related operation comprising the steps of: 
providing an object-related request from one or 
said data terminal means (18) and said image 
terminal means (21); and 

transferring said object-related request to said ob- 
ject management means (48) of said data process- 
ing system and performing an object-related opera- 
tion in conjunction with at least one of said image 
terminal means (21), said memory storage means 
(50,60,52,53) and said scanner means (22). 

2. A method as claimed in Claim 1 , wherein an 
operation to be performed is a capture operation 
(Fig. 12a, 12b) and wherein said providing and 



computing means (13) and transferring said name 
together with said temporary object identification 
characters from said host computing means (13) to 
w said object management and delivery system (12) 
to flag a capture authorization; 
entering temporary object identification characters 
at image terminal means (21) for an object to be 
scanned, and sending the entered characters to 
is said object management means (48) to verify stor- 
age authorization; 

scanning said object with said scanning means 
(22)r-once-a-storage-authorization-has-been - veri- 



fied, to produce object data corresponding to said 

20 object; and 

sending said object data to said object manage- 
ment and delivery systems (12) and storing said 
object data in said memory storage means 
(50,60,52,53) as an object data record, said object 

25 data record being associated with said permanent 
object name. 

3. A method as claimed in Claim 2, wherein 
said capture operation is performed for both a low 
image resolution and a higher image resolution, 

30 wherein said scanning step and steps recited 
thereafter are conducted a first time to produce a 
low resolution record and a second time to produce 
a high resolution record. 

4. A method as claimed in Claim 1 , wherein an 
35 operation to be performed is a prefetch operation 

(Fig. 13a, 13b), and wherein said providing and 
transferring steps further comprise the steps of: 
obtaining, at said host computing means (13), a 
prefetch request indicating a particular object for 
40 which an object record is likely to be requested for 
one of a display, modification, and printing opera- 
tion; 

generating a permanent object name correspond- 
ing to said particular object and transferring said 

45 name together with a prefetch command from said 
host computing means (13) to said object manage- 
ment and delivery system (12); and 
retrieving an object data record corresponding to 
said permanent object name and storing said 

so record in said object management and delivery 
system (12) which is associated with the requesting 
said host computing means (13). 

5. A method as claimed in Claim 4, wherein 
said method is applied in an environment where 

55 there is a plurality of respective host computing 
means (13 J 3a) each associated with a respective 
object management and delivery system (12, 12a). 
and wherein, in said generating step, said name 
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and prefetch command are instead transferred from 
said host computing means (13,1 3a) to an object 
management and delivery system (12 t 12a) likely to 
own an image data record for said particular docu- 
ment 

— fi. a mflthnd~fltt-rfa i m fl H-in CAnim 17 wh n rnin nn' 

operation to be performed is a display operation 
(Fig. 14a,14b), and wherein said providing and 
transferring steps are more specifically comprised 
of the steps of: 

entering, at said data terminal means (18), a dis- 
play request indicating a particular object to be 
displayed and sending said request to said host 
computing means (13); 

generating a permanent object name correspond- 
ing to said particular object and transferring said 
name together with a display command from said 
-host"Computing~means~(13)"tc r said"object manage- 
ment and delivery system (12); 
retrieving an object data record corresponding to 
said permanent object name and transferring said 
record to said object management and delivery 
system (12) which is associated with said data 
terminal means (18) which was used to enter said 
display request; and 

delivering said object data record and displaying 
an object image at said image terminal means (21) 
which is associated with said data terminal means 
(18) which was used to enter said display request. 

7. A method as claimed in Claim 6 , wherein 
said method is applied in an environment where 
said object management and delivery system (12) 
can store an object record as a low resolution 
record containing data corresponding to a low reso- 
lution object image, or as a higher resolution record 
containing data corresponding to a higher resolu- 
tion object image, and wherein, in performing said 
retrieving step, an attempt is made first to retrieve 
an object data record having the same resolution 
as the resolution of image monitor means upon 
which the desired object image is to be displayed, 
and if an object data record having said same 
resolution is not available, retrieving an object data 
record at a different resolution and processing ob- 
ject data of said object data record to obtain object 
data at said same resolution. 

8. A method as claimed in Claim 1 , wherein an 
operation to be performed is a print operation (Fig. 
15a,l5b) and wherein said providing and transfer- 
ring steps further comprise the steps of: 
entering, at said data terminal means (18), a print 
request indicating a particular object to be printed 
and sending said request to said host computing 
means (1 3); 

generating a permanent object name correspond- 
ing to said particular object and transferring said 
name together with a print command from said 
host computing means (13) to said object manage- 



ment.and_delivery_system-(.12); 

retrieving an object data record corresponding to 
said permanent image name and transferring said 
record to said object management and delivery 
s means (12) which is associated^ with_ said_ data 
te i n ii i Tdr rl Tea i is ( 1 87 which "was usea to enter saia 
print request; and 

delivering said object data record and printing an 

object image at an image printer means (46) which 
10 is associated with said data terminal means (18} 

which was used to enter said print request. 

9 A method as claimed in Claim 1, wherein an 

operation to be performed is a print operation (Fig. 

16a,16b; Fig. 17a,17b), and wherein said providing 
75 and transferring steps further comprise the steps 

of: 

e ntering, at said image terminal mea ns_(21),jLgnnt_ 
request indicating a particular object to be printed; 
generating a permanent object name correspond- 

20 ing to said particular object and transferring said 
name together with" a print command from said 
host computing means (13) to said object manage- 
ment and delivery system (12); 
retrieving an object data record corresponding to 

25 said permanent object name and transferring said 
record to said object management and delivery 
system (12) which is associated with said image 
terminal means (21) which was used to enter said 
print request; and 

30 delivering said image data record and printing an 
• object image at an image printer means (46) which 
is associated with said image terminal means (21) 
which was used to enter said print request. 

10. A method as claimed in Claim 8 or 9, 
35 wherein said method is applied in an environment 

where said object management and delivery sys- 
tem (12) can store an object record as a low 
resolution record containing data corresponding to 
a low resolution object image, or as a higher reso- 

40 lution record containing data corresponding to a 
higher resolution object image, and wherein said 
retrieving step is performed by retrieving a higher 
resolution record corresponding to said permanent 
object name and then processing object data of 

45 said object data record to obtain object data at a 
print resolution. 

11. A method as claimed in Claim 1, wherein 
an operation to be performed is a modify operation 
(Rg. 18a,18b) and wherein said providing and 

so transferring steps further comprise the steps of: 
entering, at said data terminal means (18), a modify 
request indicating a particular object to be modified 
and sending said request to said host computing 
means (13); 

55 generating a permanent object name correspond- 
ing to said particular object and transferring said 
name together with a modify command from said 
host computing means (13) to said object manage- 
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merit and delivery system (12); 
retrieving~an-object-data-record-cGfresponding-to- 
said permanent object name and transferring said 
record to said object management and delivery 
system (12) which is associated with said data 
terminaljneans 08) wjiich wasjj^ to_yter^ajd_ 
moony request; ~ — 
delivering and modifying said object data record at 
an image terminal means (21) which is associated 
with said data terminal means (18) which was used 
to enter said modify request; and 
sending the modified said object data record to 
said object management and delivery system (12), 
and storing modified said object data record in said 
memory storage means (50,60,52,53) as a modified 
object data rocord, said modified object data 
rocord being associated with a modified permanent 

object name . 

12. A method as claimed in Claim 1, wherein 
an operation to be performed is a modify operation 
(Fig. 19a,19b), and wherein said providing and 
transferring steps further comprise the steps of: 
entering, at said data terminal means (18), a modify 
request indicating a particular object to be modified 
and sending said request to said host computing 
means (13); 

retrieving temporary object identification characters 
from said host computing means (13) and posting 
said characters onto new object pages which are to 
be scanned; 

generating a permanent object name In said host 
computing means (13) and transferring said name 
together with said temporary object identification 
characters from said host computing means (13) to 
said object management and delivery system (12) 
to flag a modify authorization; 
entering temporary object identification characters 
at image terminal means (21 ) for new object pages 
to be scanned, and sending the entered characters 
to said object management and delivery system 
(12) to verify modify authorization; 
retrieving, once a storage authorization has been 
verified, an object data record corresponding to 
said permanent object name and transferring said 
record to said image terminal means (21) which 
was used to enter said temporary object identifica- 
tion characters; 

scanning said new object pages with said scanning 
means (22) to produce object data corresponding 
to said object, and adding said produced object 
data to object data from said object data record 
resulting in modified object data; and 
sending modified said object data to said object 
management and delivery system (12) and storing 
modified said object data in said memory storage 
means (50,60,52,53) as a modified object data 
record, said modified object data record being as- 
sociated with a modified permanent object name. 



13. A method as claimed in Claim 11 or 12, 
wherein-said-method-is-applied-in-an-environment 

wherein said object management and delivery 
system(12) can store an object record as a low 
s resolution record containing data corresponding to 

a low resolut iojiLObject Jmage, or as ajiigherjesg- 

lution record containing data corresponding to a 
higher resolution object image, and wherein said 
generating step and steps recited thereafter are 
jo conducted a first time to modify a low resolution 
record and a second time to modify a higher reso- 
lution record. 

14. A method as claimed in at least one of 
claims 6 to 13, wherein said method is applied in 

is an environment where there is a plurality of respec- 
tive host computing means (13,13a) each asso- 
ciated with a respective object management and 
deliver y systemJ12,ljte),_v^ere^ 
ject data record is stored in a remote object man- 

20 agement and delivery system which is not asso- 
ciated with the requesting said data terminal 
means, a data retrieving operation of said retrieving 
step is conducted with respect to said remote 
object management and delivery system. 

25 15. A method as claimed in at least one of 
claims 2 to 14 comprising the further step of: 
having said object management and delivery sys- 
tem (12) notify said host computing system (13) of 
said modified object data record which has been 

30 stored. 

16. In a data processing systen for storing and 
displaying digital images, including an image termi- 
nal (21) having a document scanner (22) and a 
keyboard, said image terminal (21) being coupled 

35 to an object management and delivery system, 
(12), a data terminal (18) coupled to a file manage- 
ment system (19), a storage manager (49,51) coup- 
led to and controlling first and second image stor- 
age means (50,60,52,53), wherein said object man- 

40 agement and delivery system (12) is connected to 
said file management system (19) and said storage 
manager (49,51), a method for storing an image 
and comprising the steps of: 
inputting temporary object identification characters 

45 into said data terminal (18) to identify an image; 
generating a permanent object name in said file 
management system (19) to said image by using 
said temporary object identification characters; 
transmitting said permanent object name to said 

so object management and delivery system (12); 

storing said permanent object name in said object 
management and delivery system (1 2); 
inputting said temporary object identification char- 
acters into said image terminal(21); 

65 transmitting said temporary object identification 
characters to said object management and delivery 
system (12); 

retrieving said permanent object name stored in 

17 
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said object management and delivery system (12); 



-inputting-said-image-into"said"im"ag^ter7ninar{2"tr 
by converting it to an image data stream at said 
document scanner (22); 

transmitting said image data stream to said object 
ma nagement and delivery .system ^(1 2); 
transmitting said permanent object name and said 
image data stream to said storage manager 
(49.51); 

storing said permanent object name and said im- 
age data stream in said first storage means 
(50,60,52,53); and sending a register command to 
said file management system (19) indicating that 
said image has been stored. 

17. A data processing system for storing a 
plurality of electronic object data records, and for 
displaying and reproducing a desired object using 
said data re cords_comprisinq; 



10 



15 



host computing means (13) comprising: 
file management system (19) to generate tempo- 20 
rary object identification characters and a perma- 
nent object name for said desired object, said file 
management system (19) having work files contain- 
ing data pertinent to said object data records; 
data terminal means (18) connected to said file 25 
management system (19) to provide an object re- 
lated request to said data processing system; 
object management and delivery system (12) com- 
prising: 

document scanner (22) to scan said desired object 
to produce object data corresponding to said de- 
sired object; 

memory storage means (50,60,52,53) for storing 
said object data; 

object management means (48) to store said object 
data in said memory storage means (50,60,52,53) 
as an object data record, said object data record 
being associated with said permanent object name; 
image terminal means (21) to perform image re- 
lated tasks including image display, image print, 40 
and object related requests. 
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51 - DOCUMENT ARRIVES AT MA1LR00M. 

52 - REQUEST SENT FROM WS DATA 

TERMINAL TO FMS FOR TEMPORARY 
OBJECT ID. 

53 - TEMP. 10. RETURNED; POSTED ON 
- DOCUMENT. 

54 - FMS GENERATES AND SENDS TO OMDS 

ASSOCIATED WITH REQUESTING WS 
OATA TERMINAL, A PERMANENT 
OBJECT NAME to FLAG A 
STORAGE AUTHORIZATION. 

55 - DOCUMENT MANUALLY TRANSPORTED 

TO WS DOCUMENT SCANNER. 
SB - TEMPORARY ID. ENTERED AND SENT 

TO OSDM TO VERIFY CORRECTNESS 

AND STORAGE AUTHORIZATION. 
S7a- IF INVALID TEMPORARY ID, OSDM 

REPORTS ERROR. JUMP TO S6 OR END. 
STb- IF VALID TEMPORARY ID., OSDM 

RETURNS VERIFICATION. 

58 - DOCUMENT SCANNED ? OBJECT DATA 

QUALITY VERIFIED '.OBJECT DATA 
SENT TO OSDM. 

59 - OSDM STORES OBJECT DATA USING 

PERMANENT OBJECT NAME. 
StO- STEPS S6 TO SIO REPEATED IF 
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RESOLUTION. 
Sll - OMDS NOTIFIES FMS THAT 08JECT DATA 
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S20- FMS SELECTS OBJECT FROM WORK 

QUEUE OR REQUEST MADE FROM A WS OATA TERMINAL 
S2I - PREFETCH COMMAND BUILT AND 

ASYNCHRONOUSLY TRANSFERRED TO 

OMDS LIKELY TO OWN OBJECT DATA 

FOR THE DESIREO OBJECT. 
S22- RETRIEVAL COMMAND BUILT; 

DESIRED OBJECT DATA RETRIEVED 5 

OBJECT DATA TRANSFER TO OMDS 

ASSOCIATED WITH REQUESTING FMSORWS 

DATA TERMINAL. (NOTE: |F A 

REMOTE OMDS OWNS THE 

OBJECT DATA FOR THE DESIRED 

OBJECT, DASHED ( ) 

PROCESSING PATH P22a AND P22b 

REQUIRED. IF PREFETCH COMMAND 

INITIALLY TRANSFERRED TO 

REMOTE OMDS, ONLY 

DASHED ( ) PROCESSING PATHS 

P2lb AND P22b REQUIRED.) 

S23 - OSDM ASSOCIATED WITH REQUESTING FMS OR 
WS DATA TERMINAL STORES 
TEMPORARY COPY OF OBJECT DATA 
FOR FUTURE ACCESS. 
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AN ERROR IS ENCOUNTERED.) 
RETRIEVAL COMMAND BUILT s 
DESIRED OBJECT DATA RETRIEVED i 
OBJECT DATA TRANSFER TO OMDS 
ASSOCIATED WITH REQUESTING WS 
DATA TERMINAL. (NOTE • IF A 
REMOTE OMOS OWNS THE 
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- FMS BUILDS A PRINT COMMAND. 

- PRINT COMMAND TRANSFERRED 
ASYNCHRONOUSLY TO OMDS 
ASSOCIATED WITH SUBJECT 
PRINTER. (NOTE: NO RESPONSE 
RETURN TO FMS UNLESS AN 
ERROR IS ENCOUNTERED.) 
RETRIEVAL COMMAND BUILT: 
DESIRED OBJECT DATA RETRIEVED : 
OBJECT DATA TRANSFER TO OMDS 
ASSOCIATED WITH SUBJECT 
PRINTER. (NOTE : IF A REMOTE 
OMDS OWNS THE OBJECT 
OATAFOR THE OESIREO OBJECT, 
PASTO"^ PROCESSING PATH P43o 
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FIG. I6B. 



S50 - PRINT REQUEST MADE AT WS IMAGE 
TERMINAL. 

$51 - IMAGE TERMINAL BUILDS PRINT 
COMMAND. 

S52o - IF PWS IMAGE TERMINAL CONTAINS 
OBJECT DATA RESOLUTION SUFFICIENT 
FOR PRINTING, PRINT COMMAND AND 
OBJECT OATA TRANSFERRED TO PWS 
PRINTER. JUMP TO S55. 

S52b- IF NOT. PRINT COMMAND 
TRANSFERRED TO OMDS 
ASSOCIATED WITH SUBJECT PRINTER. 

553 - RETRIEVAL COMMAND BUILT; DESIRED 

OBJECT DATA RETRIEVED ; OBJECT DATA 
TRANSFER TO OMDS ASSOCIATED WITH 
SUBJECT PRINTER. (NOTE: IF A 
REMOTE OMDS OWNS THE OBJECT 
OATA FOR THE DESIRED OBJECT. 

OASHEO ( ) PROCESSING PATH P53o 

AND P53b REQUIRED.) 

554 - PRINT COMMAND TRANSFERRED WITH 

OBJECT DATA THROUGH PWS IMAGE 
TERMINAL TO PRINTER FOR PRINTING. 

555 - PRINT OPERATION ERRORS REPORTED TO 

IMAGE TERMINAL ORIGINATING THE 
PRINT REQUEST. 
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FIG I7B. 



560 - PRINT REQUEST MADE AT WS IMAGE 

TERMINAL. 

561 - IMAGE TERMINAL BUILDS PRINT 

COMMANO. 

562 - PRINT COMMAND TRANSFERRED TO 

OMDS ASSOCIATED WITH SUBJECT 
PRINTER. 

S63a- IF WS IMAGE TERMINAL CONTAINS 
OBJECT DATA RESOLUTION 
SUFFICIENT FOR PRINTING. OBJECT 
DATA TRANSFERRED TO OMDS 
ASSOCIATED WITH SUBJECT 
PRINTER. JUMP TO $64. 

S63b- IF NOT, RETRIEVAL COMMAND 
BUILT: DESIRED OBJECT OATA 
RETRIEVED ; OBJECT DATA TRANSFER 
TO OMDS ASSOCIATED WITH SUBJECT 
PRINTER. (NOTE J IF A REMOTE 
OMDS OWNS THE OBJECT 
DATA FOR THE DESIRED OBJECT, 

DASHED ( ) PROCESSING PATH P63b 

AND P63c REQUIRED.) 

564 - PRINT COMMAND TRANSFERRED WITH 

OBJECT OATA THROUGH PWS IMAGE 
TERMINAL TO PRINTER FOR 
PRINTING. 

565 - PRINT OPERATION ERRORS 

REPORTED TO IMAGE TERMINAL 
ORIGINATING THE PRINT REQUEST. 
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FIG. I8B. 
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570 - MODIFY REQUEST AT WS DATA TERMINAL 

571 - FMS BUILDS A MODIFY COMMAND. 
S72- MODIFY COMMAND TRANSFERRED 

ASYNCHRONOUSLY TO OMDS ASSOCIATED 
WITH REQUESTING WS DATA TERMINAL. 
CNOTE : NO RESPONSE RETURN TO FMS 
UNLESS AN ERROR IS ENCOUNTERED OR 
STORAGE ACKNOWLEDGMENT MADE.) 
RETRIEVAL COMMAND BUILT; DESIRED 
OBJECT DATA RETRIEVED : OBJECT DATA 
TRANSFER TO OMDS ASSOCIATED WITH 
REQUESTING WS DATA TERMINAL. 
(NOTE : IF A REMOTE OMDS OWNS 
OBJECT DATA FOR THE DESIRED 

OBJECT. OASHED ( ) PROCESSING 

PATH P73a AND P73b REQUIRED.) 

OBJECT DATA TRANSFER TO WS IMAGE 
TERMINAL. 

MODIFICATION PERFORMED AT WS IMAGE 
TERMINAL AND TRANSFERRED BACK TO 
OSOM WITH STORE COMMAND. 

MODIFIED OBJECT DATA STORED. 

$H^^M N0WI - E0GM ENT OF STORE 
TOWS IMAGE TERMINAL 

578 - STEPS S74 TO S78 REPEATED IF 

MODIFY IS TO ALSO BE CONDUCTED 
AT DIFFERENT RESOLUTION. 

579 - OSDM NOTIFIES FMS THAT MODIFIED 

OBJECT DATA HAS BEEN STORED. 
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FIG. I9A. 
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■ TRANSPORT PAGES TO WS DOCUMENT SCANNER. 

■ TEMPORARY ID. ENTERED AND SENT OSDH. 

• IF INVALID ID., ERROR REPORT. JUMP TO $85. 

• IF VALID TEMP ID.,OSDH VERIFICATION. 

■ RETRIEVAL COMMAND BUILT « DESIRED OBJECT 
DATA RETRIEVED 5 OBJECT DATA TRANSFER TO 
OMDS ASSOCIATED WITH REQUESTING WS IMAGE 
TERMINAL. INOTEMF A REMOTE OMDS 

OWNS OBJECT DATA FOR THE DESIRED 

OBJECT, OASHED ( ) PROCESSING PATH P87a 

ANO P87b REQUIREO.) 

-TRANSFER TOWS IMAGE TERMINAL. 

■ MODIFY BY SCANNING NEW PAGES AT WS IMAGE 
TERMINAL? TRANSFER BACK TO OSOM WITH 
STORE COMMAND. 

■ MODIFIED OBJECT DATA STORED. 

- OSDM SENDS ACKNOWLEDGMENT OF STORE TO WS 
IMAGE TERMINAL 

■ STEPS S87 TO S92 REPEATED IF MODIFY ALSO 
TO BE CONDUCTED AT DIFFERENT RESOLUTION. 

■ FMS NOTIFIED MODIFIED OBJECT DATA STORED. 
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